home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13394 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.6 KB
  1. Path: imonics.com!not-for-mail
  2. From: rcook@imonics.com (Imonics Corporation)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Portability of code & skills (Beware of "C" Hackers etc)
  5. Date: 25 Mar 1996 09:55:04 -0500
  6. Organization: Imonics Corporation
  7. Message-ID: <4j6c48$4mr@bughouse.imonics.com>
  8. References: <4ikb6kINN1is@mayne.ugrad.cs.ubc.ca> <3150415E.6396@sdt.com> <4ip5om$s9@bughouse.imonics.com> <4isfcu$p09@news1.mnsinc.com>
  9. NNTP-Posting-Host: bughouse.imonics.com
  10.  
  11. In article <4isfcu$p09@news1.mnsinc.com>,
  12. Szu-Wen Huang <huang@mnsinc.com> wrote:
  13. >Imonics Corporation (rcook@imonics.com) wrote:
  14. >
  15. >: I think Unix and C are a success because they are deliberately
  16. >: obscure.  All those "computer science" graduates just love
  17. >: knowing a secret code with which they can amaze people.  They
  18. >: don't WANT it to be easy to understand; that would mean that
  19. >: other people could and would read their code and be able to do
  20. >: the things they do.  That would weaken their club membership
  21. >: (sort of like letting in girls is to 7-year-olds).
  22. >
  23. >That's not really fair.  In the beginning, only countries can
  24. >afford computers.  Then big businesses.  Then scientists.  Unix
  25. >was born at a time when scientists were beginning to buy computers
  26. >to aid their work, and really heralded what we now call general-
  27. >purpose computing.  Unix fit quite well to this task, despite its
  28. >shortcomings in architecture.  Unix was never meant to be for non-
  29. >experts, that's quite clear.  It is not so much a deliberate "club
  30. >membership" attempt as it is simply easier for experts to use
  31. >expert-talk and expert-tools.  You are twisting the motive in your
  32. >post, because the objective is to be lean and mean, not to be
  33. >deliberately obscure.  The obscurity was a necessity when the
  34. >machines had such limited capacities.
  35.  
  36. Well, you got the "mean" part right.  As for not being for non-experts,
  37. there sure are a lot of people touting Unix as the only good
  38. operating system for any purpose.  Sheesh.
  39.  
  40. As for "necessity": it is not necessary to name the list files command "ls", 
  41. the help function "man", the print function "lp", and the editor "vi".
  42. It is not and was never necessary to limit options to single case-
  43. sensitive letters so that you have to remember all the magic mumbles
  44. to do your work.  It is not necessary to give "cute" names to things
  45. (say, "set noclobber").  These things don't save enough space to be
  46. worth mentioning, even on the old 8-bit machines.  I don't believe
  47. that's why it was done; do you have any evidence?  Would it have
  48. taxed those early systems if the "ls" command had been named, say,
  49. "list"?  Or "dir"?
  50.  
  51. I think part of it is blindness -- I think those people honestly think
  52. that, if an abbreviation is good enough for them, it is good enough for
  53. everyone.  That's why the namespace for Unix commands is such a bloody
  54. mess.  They couldn't even keep consistent within their own commands;
  55. "cd" for "change directory", but "pwd" for "print working directory".
  56. Well, is it a "directory" or a "working directory"?  Come to think of
  57. it, when else is it ever called a working directory?
  58.  
  59. But I really do think that most of it is fascination with the ultimate
  60. video game.  Look at this neat thing I can do, all I have to enter
  61. is "awk -syLgX -poop -l cfgfile".
  62.  
  63. And, yeah, I can define aliases for commands as I want.  But it should
  64. not be the purpose of aliases to bring order to the chaos.  And all the
  65. documentation, such as it is, uses the obscure names for everything.
  66. I'm sorry, but your argument that it was necessary on limited machines
  67. doesn't hold water.  Can you come up with anything better?  
  68.  
  69. >Software and hardware engineering have been becoming more and more
  70. >quantitative and scientific.  More and more people are starting to
  71. >profile before optimizing.  I don't see what you're complaining about.
  72. >There will always be poor engineers.
  73.  
  74. What I'm complaining about, in this particular paragraph, is your very
  75. argument -- "when computers were smaller, this was necessary".  My point
  76. is that it was never necessary to save microseconds in a piece of code
  77. just before the system prompted the user for an answer to something.
  78. I'm not talking about a general-purpose routine, or something in a loop,
  79. but cases where people seem to worry about tiny performance issues
  80. even while they're gathering requirements, before they have any notion
  81. of whether or where performance problems will be.
  82.  
  83. That whole mindset of saving microseconds has been poor engineering since
  84. at least my entry into programming, on F8s and Z80s, in 1977.  It's a
  85. red herring, meant to justify poor engineering that hasn't been "necessary"
  86. (at least) since 3rd-generation languages became common.
  87.  
  88. Ralph Cook
  89.